The present invention relates in general to communication systems, and is particularly directed to a link pre-establishment control mechanism incorporated into the control software employed by the microcontroller of integrated services digital network (ISDN) terminal equipment, for determining the service profile identifier (SPID) of the telecommunications switch installed by the local service provider to couple the customer""s equipment with the network, so that the terminal equipment may gain connectivity (place a call) through the switch and over the network to a destination site.
Integrated services digital network (ISDN) communications enable telephone service providers to supply multiple types of signalling channels from a central office over a single twisted pair-configured, local loop to a network termination interface or ISDN terminal equipment, such as, but not limited to an ISDN phone, an X.25 packet device, or an ISDN terminal adapter, to which customer premises-resident data terminal equipment may be coupled.
These multiple types of signalling channels typically include a digital data channel, a digitized voice channel and a separate dialing channel. Since the ISDN terminal equipment is customer-installed, the local telephone service provider does not participate in the customer""s choice of equipment to be connected to the ISDN line.
However, in order for a customer to actually place a call through an installed piece of terminal equipment, it is necessary that the terminal equipment""s supervisory communications controller be properly initialized or preconfigured with a prescribed set of communication parameters. These parameters include the telecommunications switch protocol employed in the local service provider""s central office facility, the local directory numbers (LDNs), including area codes, associated with the two ISDN bearer (B1, B2) channels, and a service profile identifier or SPID. The SPID is a sequence of digits, which identifies the ISDN terminal equipment that is coupled to the ISDN switch, and is assigned by the local telephone service provider, when the ISDN line is installed. The number of SPIDs required (0, 1 or 2) will depend upon how the ISDN line is configured.
Now although the switch protocol and SPID parameters are routinely supplied by the telephone service provider to the purchaser of the ISDN terminal equipment equipment, the user is usually technically unsophisticated and accustomed to doing nothing more than simply installing an analog modem in the customer""s premises-located equipment, and plugging in a telephone connector to a modem port (RJ 11 jack). Indeed, experience has shown that on the order of eighty percent of ISDN customers will burden the equipment supplier and/or the local telephone service provider with requests for technical support in the course of configuring the settings for ISDN terminal equipment, irrespective of whether the service provider has correctly assigned each of the switch protocol, SPID and LDN parameters for use by the customer""s ISDN terminal equipment.
In accordance with the present invention, the user""s (actual or perceived) inability to properly configure ISDN terminal equipment, even when provided with correctly assigned switch protocol, SPID and LDN parameters by the telephone service provider, which places a labor-intensive service burden on the equipment supplier and/or the local phone company, is successfully remedied by a SPID/switch detector mechanism that is incorporated into the terminal equipment""s communications control software. The only customer participation required is that of inputting the local directory numbers, and invoking the SPID/switch detection mechanism via a user interface.
Upon being invoked, the SPID generator mechanism proceeds to step through a prescribed SPID table search and generation routine, followed by a test call communication exchange with the telecommunications switch employed by the local service provider to couple the customer""s equipment with the network. During this process, the control mechanism iteratively attempts to register respectively different service profile identifiers (SPIDs), as necessary, until the correct SPID and corresponding switch protocol is identified.
As will be described, the SPID/switch protocol detection mechanism is an exclusionary process, which attempts to bring up the line or register a SPID in an iterative or stepwise manner, proceeding through respective SPID format loops associated with separate tables or list entries for respectively different switch protocols that may be employed by the local service provider. For the above-referenced examples of switch protocols currently employed by telephone service providers, the present invention accesses two respectively different SPID tables, one of which contains entries for an ATandT switch protocol (ATandT Custom), and the other of which contains two successive sets of entriesxe2x80x94one for a National ISDN switch protocol (e.g., NIxe2x88x921 or NIxe2x88x922) and the other for a DMS switch protocol (Northern Telecom DMS-100 Custom). At the start of the iterative search, the routine sets the SPID format index to zero, sets the switch protocol to National ISDN, and resets the link.
The SPID format routine then looks for a specific switch protocolxe2x80x94ATandT Custom (which also has a reduced number of table entries, allowing an expedited SPID format search). If the switch protocol is ATandT Custom, the subroutine accesses the ATandT SPID format table. If not, the SPID format subroutine accesses the table containing listings for National and DMS-100 SPID formats.
Once a SPID format table has been selected, suffix and prefix codes are generated, as necessary. (If there is no prefix and no suffix code and ATandT protocol had been selected, a point-to-point connection (involving no SPID) is inferred.) The prefix code is examined to determine whether it indicates an area code entered by the user. If so, the three digit area code entered by the user is employed as the SPID prefix. If there is no three digit prefix code, the prefix code is examined to determine whether it is the two digit prefix code 01. If so, the two digit code xe2x80x9801xe2x80x99 is used as the SPID prefix. If neither of these prefixes is found, no prefix code is used. Once the prefix code has been determined, a zero to four digit suffix code is generated from whichever SPID format table was selected.
Given both prefix and suffix codes (plus the local directory number(s) entered by the user, one or two SPIDs are respectively defined as the combination of the prefix code, the first/second local directory number (LDN) entered by the user and the suffix code. If the terminal equipment has only one phone number, the second (non-existent phone number-associated) SPID is designated as xe2x80x98nonexe2x80x99.
With the SPID or SPIDs determined, an attempt is made to bring up the line (registering the SPID(s)). If the attempt is successful, it is inferred that the SPID(s) and associated switch protocol are correct and a test call sequence is invoked. However, if the attempt to bring up the line using the derived SPID(s) is unsuccessful, the process executes sequence of operations to determine the reason for the failure.
For this purpose, during the initial attempt to select and register the proper National ISDN SPID format, the routine checks for characteristic behavior of ATandT switches, namely, the receipt of any Management Information Message (MIM), or receipt of a call set-up message containing an invalid reference number. As such responses are unique to ATandT switches, if received, it is inferred that the switch is an ATandT switch and the process selects ATandT custom protocol and resets the SPID format index to zero. It then transitions to a SPID table exhaustive search subroutine. However, if no xe2x80x98ATandTxe2x80x99 responses have been received, it is inferred that the switch is not an ATandT switch and the process does not change the initially selected National ISDN switch protocol and SPID format index.
During the course of the SPID format search, the table of SPID format indices is stepped or advanced, one index entry at a time, to the next SPID index, until all of the table entries have been tried. If no table entry has been able to produce the required SPID, a failure to generate a SPID is inferred and the routine is terminated. With each one or two new SPIDs generated from the next table entry, the routine attempts to bring up the line (register the generated SPID(s)). If any attempt to bring up the line is successful, it is inferred that the derived SPID and switch protocol for that attempt are correct, and the process then branches to a test call subroutine.
In the test call routine, if only one LDN has been entered by the user, the routine attempts to call that number. If two phone numbers have been entered, the first entered number is used as the xe2x80x98callingxe2x80x99 number and the second number is employed as the xe2x80x98calledxe2x80x99 number. The terminal equipment places a test call to the called number. To distinguish between National ISDN and DMS-100 protocol, the test call contains a low layer compatibility information element, which is specified under National ISDN, but not under DMS custom. The routine also monitors test call progress for receipt of a prescribed status message associated with the behavior of DMS Custom switch protocol.
Once the call is placed, a time-out is invoked. If the call is received from the switch within a prescribed period of time (e.g., within 30 seconds), it is inferred that the determined SPID/switch protocol is correct. However, if the switch returns a failure indication or the time-out expires before the call is received from the switch, the called number is modified by adding a prefix xe2x80x9c9xe2x80x9d to the LDN, and the call is redialed. Again, the redialed call must be received from the switch within the prescribed time-out period. If so, it is inferred that the determined SPID/switch protocol is correct. If not, the test call fails and the process is terminated.
Once a test call (or redialed test call) has been successfully placed, a determination is made as to whether the selected protocol is ATandT Custom switch protocol, a National ISDN switch protocol or a DMS-100 switch protocol. If the selected protocol is not ATandT Custom, an inquiry is made as to whether the test call returned a status message containing the Cause IE equal to 43 (ACCESS INFO DISCARDED), which is characteristic of DMS custom switch protocol. Since the test call contains a low layer compatibility information element, specified under National ISDN, but not under DMS custom, the test call progress can be monitored for a prescribed status message associated with the behavior of DMS Custom switch protocol. If the iterative SPID search has advanced beyond the last National ISDN entry, DMS behavior is inferred. If DMS behavior is not detected, it is concluded that the SPID is associated with National ISDN switch protocol.